We performed some measurements with a portable magnetometer: 3-axial magnetic probe FL3 100 Stefan Mayer. 

Figure 1 compares spectra recorded in two locations:

• "EXTMAG chs X,Y,Z" the probe was placed on the soil nearby the buried external magnetometer
• "GUARD3 chs X,Y,Z" the probe was on the soil next to the vent tube of the methan gas pipeline, this is located inside the EGO fence next the EGO guardiania, see the attached pictures.

The GUARD3 spectra clearly show the noise: 0.23 Hz spaced lines peaking at 8Hz. The peak amplitude (spectra are obtained with 25s window) is approx 2 nT/sqrtHz. Which is a factor approx 100 larger than measured in the location EXTMAG, but similar to that measured by the magnetometers on the NI and WI tower base. Might be due to telluric currents in the chambers?  

As a check of the probe calibration, in Figures 2 and 3 we compare the EXTMAG measurement with that of the buried magnetometer, ENV_EXT_MAG_N. The fluxgate probe is more noisy (intrinsic noise) but around 8Hz they are measuring the same.

The indication is that the magnetic disturbance is radiated from the methan gas pipelines. A noise clearly associated to the power supply for galvanic currents in these pipelines was observed in the year 2022 (55542 and 57973). At that time the noise was shaped as approx. 5Hz comb. 

Federico has contacted the methan gas company (SNAM) to investigate further the source.

Today also FIAMM01 (Carabinieri) had some flyover near CEB (08:40 UTC)

The estimated distance is ~ 200m, the height was ~ 200m (credits: flightradar24), well inside the NOTAM area.

The signal is very clearly visible in the CEB microphones. The ITF was unlocked (maintenance).

The probe has been removed today from the MC tube, during the maintenance.

The ENV_MCB_MAG_N magnetometer was defective as of October 2, 2023 at 00:03:05 UTC.

Today we changed it with a new one (MFS-06e). We also had to use a different type of cable (the new magnetometer uses a different connector), via an adapter.

The signals seem to have returned to normal values.

A new noise is seen in the external magnetometer starting April 22 19:56 UTC. Figures 1 and 2. The noise has been detected and studied by Renato and Federico. Here is a report of the investigation so far.

The noise is impulsive, as seen in Figures 3,4,5. Observed in the time domain it consists of a carrier at about 8Hz switching on-off with a cycle of approximately 4.4s (0.23 Hz): on for 2.2s and off for 2.2s.

The noise is seen by all magnetometers site-wide. Internal magnetometers sees it a factor up to about 10 larger than the external "N" magnetometer, in Figure 6 and Figure 7 (the EXT_N magnetometer is the gray spectrum in all 3 plots). Magnetometers that see it a bit more intense are those close to NI, WI and WE towers.

A close look to the narrow spectral structure of the noise shows that it does not follow the mains, in Figure 8.

These hints suggest a DC-powered PWM source (Federico).

Bruco runs using ENV_NI_MAG_V as target, and EXCLUDING all magnetometers (ENV_*MAG*) channels, show that this disturbance is not coherent with any other ENV channel (https://scientists.virgo-gw.eu/DataAnalysis/DetCharDev/bruco/users/fiori/ENV_NI_MAG_V_1397853318_ENV/) with the exception of a small coherence with the ENV_CEB_ELECTRIC. In particular no coherence, nor evidence of the noise is seen in all IPS and UPS probes. No coherence is also measured with any other Virgo signal (https://scientists.virgo-gw.eu/DataAnalysis/DetCharDev/bruco/users/fiori/ENV_NI_MAG_V_1397853318/). While s is a good news for the interferometer, it does not help much locating the source.

Measurements will be done also to check for possible external sources, like it was for galvanic currents in the natural gas pipelines (https://logbook.virgo-gw.eu/virgo/?r=55542).

As observed by Federico, the metronix magnetometer in MCB is having an issue starting from 2023 October 2 UTC 00:03:03 (Figure 1). The signal looks corrupted (Figure 2).  This does not seem an issue with the ADC and neither with the driving electronics, since other channels sharing the same boards are fine. We will investigate further at next maintenance.

This fauty condition was not signalled by the DMS DeadChannel since the associated rms was smaller than the set threshold. The rms threshold has been updated (0.35 to 1 nT) and this channel temporary shelved.

The altitude was also very low at the closest point (400ft --> 120mt).

" So probably the helicopter respected the NOTAM. "

I guess not

Tonight a strong and clean PC_1 magnetic pulsation was received in both the underground magnetometers of Sos Enattos and the external magnetometer of Virgo.

Here its "sound" when accelerated and shifted in frequency 100 times.

 (credits: Renato Romero www.vlf.it)

This is a first (preliminary) look at the effect of acoustic injection into Hrec, performed on Thursday 18.

For each injection (at the 0.03, 0.04 and 0.05 V levels) the BNS range decreased.

Here the entire Hrec range from 10 to 1000 Hz.

There are regions growing at low frequency (around 120 and 170 Hz) and high frequency (the most relevant from 500 to 540 Hz).

Below 100 Hz nothing seems to have changed significantly.

We tested the sensitivity of the top-stage BS accelerometers at three different levels of acoustic injection (nominally 0.03 - 0.04 - 0.05 V).

• Pink = no noise, Orange = 0,03, Green = 0.04, Grey = 0.05, Blue = narrow filter

Noise was filtered from 8 to 2000 Hz, but the actual noise produced was only from 20 Hz and up, as the speaker is unable to go lower.

The fourth injection (18:04:40 UTC - (80 -100) Hz, 300 sec, 0.04 V) aimed to produce the same level around the frequency of ~93 Hz (without generating out-of-band noise) where one of the horizontal BS F0 accelerometers (Sa_BS_F0_ACC_H3_500Hz) is usually excited during acoustic injections, in order to check whether the coupling is linear or not.

• Blue = no noise, Green = narrow noise, Pink = broadband noise

Unfortunately, the filter was too narrow, and the noise spectral density at 93 Hz was lower than expected.

However, we can say that generating a higher level by a factor of 2 (with no noise at lower frequencies) resulted in an increase of the peak by about a factor of 2 (difficult to estimate accurately). It appears that there is no upconversion and the system is "linear."

During this test we also noticed that there is some (unexplained) coherence between the upper stage F0 accelerometers and the lower external magnetometers (this is also the case in other towers besides BS).

At first glance one might think of general coupling due to the external accelerometer cables running not too far from the magnetometers (as indeed they are), but there are high-level signals in the acceleration spectrum that have no coherence. If it were a coupling from the cable, it should be broadband.

We performed a set of four acoustic injections in CEB with the AcousticInjectionCEB VPM process:

1) 17:07:55 UTC - (8 - 2000) Hz, 600 sec, 0.03 V

2) 17:21:05 UTC - (8 - 2000) Hz, 600 sec, 0.04 V  (25 min glitch at ~17:29:24 UTC)

3) 17:33:48 UTC - (8 - 2000 )Hz, 600 sec, 0.05 V

4) 18:04:40 UTC - (80 -100) Hz, 300 sec, 0.04 V

The directory path of output files is /virgoData/NoiseInjections/AcousticInjectionsO4/output. The list of file injections is reported below:

1) AcousticColored_NOISE_CEB_DetTerrace-1397495261.txt

2) AcousticColored_NOISE_CEB_DetTerrace-1397496052.txt

3) AcousticColored_NOISE_CEB_DetTerrace-1397496814.txt

4) AcousticColored_NOISE_CEB_DetTerrace-1397498666.txt

The issue with the extra spike at the beginning of the colored noise injection was related to time settings in the ACL commands in the ENVnoise process. These modifications were made by Alain (on March 26):

Figure 1 shows the result of the test: blue is with the OLD settings, purple is the with the NEW settings (the same colored noise with amplitude 0.025 V has been injected in both cases). The spike is no longer present.

The same test was done by injecting the colored noise from the ENVnoise and also using the ENV_MAIN node which calls the AcousticInjectionCEB process.

The increased coherence with ENV_NEB_IPS_CURR seems associated to the accidental presence of a glitch in hrec (one of the 25-min glitches) and a glitch in the ENV_NEB_IPS_CURR sensors.

The two glitches are NOT coincident indeed but a few sec away (the IPS glitch occurs after), but they both fall in the 10s window of the Bruco computation.

Figure 1: coherences are computed 120s before the glitch (purple) and in a 120s window containing the glitches.

Figure 2: spectrograms show that the two glitches are a few seconds away. The COHETIME plot implemented in dataDisplay measures a sort of "anti-coherence" (the coherence goes to a lower value in the time window that contains both glitches).

It is not clear what is peculiar to the NEB_IPS_CURR sensor glitch to produce coherence with Hrec?

I no longer see the useful channel Hrec_hoft_20000Hz_Gated_500Hz, missing since April 8, 2024 @ about 10:00 UTC. Am I wrong?

Today the DaqBox 169 was replaced with the DaqBox 126 with the following mezzanines:

• Slot0: mezzanine ADC +/-10V nbr 84
• Slot1: mezzanine ADC +/-10V nbr 188
• Slot2: mezzanine ADC +/-10V nbr 252
• Slot3: mezzanine ADC +/-10V nbr 262

The DaqBox 169 was not working anymore since yesterday. The DaqBox was showing abnormal functioning since March 21.
https://logbook.virgo-gw.eu/virgo/?r=63851

This DBox destruction is explained by mice (or other animals...) which defecated on the DBox.

The DBox 126 was reconfigured at 9h44m40 UTC.
2024-04-09-09h44m40-UTC    info letendre     'Reload config' sent to SWEB_dbox_rack

On Friday afternoon, while checking the power supply of some accelerometers on the DET terrace, we noticed that the flashing yellow light of the LargeCoil was ON. Indeed, the power amplifier was ON (but without any signal sent from the DAC).

Trying to turn it OFF via the Process Online Monitoring page, we found the LargeCoil_CEB gray (NEB and WEB were correctly green). The process could not be restarted. The box remained gray and the relay powering the amplifier remained in the "1" state.

Today I tried again from remote and the process restarted. I turned off all the relays at 10:51:10 UTC - There is a huge spike on the monitoring channels (ENV_CEB_MAG_COIL_CURR_MON and ENV_CEB_MAG_COIL_VOLT_MON), but it is a fake signal due to the fact that these signals are coming from the power amplifier that turned off (nothing is visible in the CEB magnetometers and in Hrec).

We will check the system again during commissioning (Monday afternoon), also because it seems that the status of the relays visible to the right of the green box is always zero, even though they are (really) set to 1.

This is a follow up of https://logbook.virgo-gw.eu/virgo/?r=63649

Friday afternoon we used two hours of commissioning to test the ENV_MAIN metratron node. The ITF was locked in LOW_NOISE_3_SQZ, COMMISSIONING.

WE performed this sequence of environmental injections:

• magnetic injection far field in CEB with the wall coil: 300s, sweep 8 Hz to 1000 Hz, 9V to the DAC
• magnetic injection far field in NEB with the wall coil: 300s, sweep 8 Hz to 1000 Hz, 9V
• magnetic injection far field in WEB with the wall coil: 300s, sweep 8 Hz to 1000 Hz, 9V
• acoustic injection in the CEB  with the loudspeaker positioned in the DET terrace: 60s colored noise 8 - 2000 Hz, 0.025 V to the DAC

The magnetic injection was succesfully performed at CEB, NEB and NEB (Figure 1). The 9V amplitude although close to the limits for current (6Apk) and Voltage (70Vpk) did not saturate the amplifier (Figure 2). With this amplitude the signal is seen sufficiently well in hrec for NEB and WEB up to about 100Hz. For CEB the signal in hrec looks not so loud (Figure 3) but we might gain a bit by doubling the injection time to 600s. For NEB and WEB the Bartington magnetometers ENV_NE(WE)_MAG_V,N,W placed close to the NE(WE) tower have to be used for the coupling function computation,  because the metronix magnetometers on NEB and WEB saturate for the low frequency part of the sweep.

The output files were successfully produced in the designated directory: /virgoData/NoiseInjections/MagneticInjectionsO4/output/ and /virgoData/NoiseInjections/AcousticInjectionsO4/output/

One thing that is useful to be implemented in is that once the sweep injection is concluded a few seconds are waited before switching off the amplifier.

Instead the acoustic injection did not preform as expected because the large spike noise at the beginning of the injection appeared again (!) and of course unlocked the ITF: Figure 4

Indeed, to our understanding this should not have happened since the used

/virgoDev/Automation/userapps/ENV_MAIN.py

now points to the patched version of the code (v2r1p1), which when tested by launching the AcousticInjectionCEB process from the VPM performed ok (i.e. no spike)

.... reading from the ENV_MAIN.py:

#        noise_injection_script = "/virgoDev/EnvSwepts/v2r2/Linux-x86_64-CL7/bin/AcousticColoredInjection-conda /virgoData/NoiseInjections/ENV/AcousticInjectionCEB.cfg"
        noise_injection_script = "/virgoApp/EnvSwepts/v2r1p1/Linux-x86_64-CL7/bin/AcousticColoredInjection-conda /virgoData/NoiseInjections/ENV/AcousticInjectionCEB.cfg

We need Franco or Rhys to have a look into this.

Considering also the TCS room temperature probe we can observe that the TCS temperature probe reacts before the Bottom TE (faster propagation in Air due to the Etalon driver than on the tower due to the belt). The anticipation time is ~ 90 min. It seems then the glitch producer is not in the TCS room

Answering a question that arose during today's commissioning meeting: the TCS room temperature variation (1.6 degC) obtained opening the door was performed while the ITF was having lock problems (NEB noise), so there are few glitch samples available for refined analysis.

However, looking at past data, we can see that the TCS room already had the same variations, so we can analyze the old data to find a correlation with the glitch rate at 25m.

The TCS door left open seems not to alter the 25m glitch rate, but some effect is visible at the CHROCC level

We had suspected that these glitches, whose repetition time is somehow correlated with the temperature of the NI Etalon heating belts, were generated in some NI Sa or Sc board.

Apart from disconnecting the mirror coils done a few days ago, which did not bring any results, we recently found a way to measure the temperature of the DSP boards.

In addition, we have recently changed the fan speed of the DSP boards several times.

As a result, each time we were able to change the temperature of the NI boards (about 5 degrees), but it seems that the glitch rate did not change. This leads us to assume that the DSP Sa and Sc boards are not the glitch generators. (*)

* Left out of this test are the power supplies that are housed in the same crates as the DSPs and supply power to the boards, because they are not directly affected by fan speed and temperature variations. But it is also true that 1) their boxes are more or less in the same environment (the crates), and they probably feel some temperature variation as well, although not that significant; 2) there is no indication that they feel the temperature variation of the etalon.

Today at 09:10 UTC we moved the thermal probe ENV_NI_ELE_CRATE_TE to the NI F1 vacuum flange to better understand the heat propagation along the vacuum vessels.

We also took the opportunity to UNPLUG all mains cables feeding the NI motor crates, as done in the past (they were all disconnected on 26/09/2023 and all reconnected on 01/12/2023).

Having a look at the microphones, we see that there was a first speed increase of +10% at 14:11:00 UTC (from 270 Hz to 300 Hz) when the control was set from "5" to "10."

Then another +10% (from 300 Hz to 330 Hz) at 15:40:00 UTC due to a further speed increase from "10" to "15."

The best witness is ENV_EQB2_MIC

At 15:15 LT fan speed level of Sc_NI crate has been increased from 5 to 10 to investigate the 25-min-glitches. It will be reverted to previous value after the weekend.